In hierarchical virtual storage systems, intensively used and frequently accessed data is stored in fast but expensive memory. One example of a fast memory is a direct access storage device (“DASD”). In contrast, less frequently accessed data is stored in less expensive but slower memory. Examples of slower memory are tape drives and disk drive arrays. The goal of the hierarchy is to obtain moderately priced, high-capacity storage while maintaining high-speed access to the stored information.
One such hierarchical storage system is a virtual tape storage system (“VTS”) including a host data interface, a DASD, and a number of tape devices. When the host writes a logical volume, or a file, to the VTS, the data is stored as a file on the DASD. Although the DASD provides quick access to this data, it will eventually reach full capacity and a backup or secondary storage system will be needed. An IBM 3590 tape cartridge is one example of a tape device that could be used as a backup or secondary storage system.
When the DASD fills to a predetermined threshold, the logical volume data for a selected logical volume is then appended onto a tape cartridge, or a physical volume, with the original left on the DASD for possible cache hits. When a DASD file has been appended to a tape cartridge and the original remains on the DASD, the file is “premigrated.”
When the host reads a logical volume from the VTS, a cache hit occurs if the logical volume currently resides on the DASD. If the logical volume is not on the DASD, the storage manager determines which of the physical tape volumes contains the logical volume. The corresponding physical volume is then mounted on one of the tape devices, and the data for the logical volume is transferred back to the DASD from the tape.
Typically, a database containing information that links the logical volumes to their corresponding physical tape volume is maintained by the VTS. Generally, the database is maintained and backed up separately from the data tapes. From time to time, the data tapes may need to be exported from a source VTS to a target VTS. Currently, exportation of the data tapes requires a copying of all of the data from all source tapes in the source VTS to all target tapes of the target VTS, which is inefficient in terms of data processing power and time. In fact, in would be more efficient just to output all of the source tapes from the source VTS as the target tapes for the target VTS, but this can be impractical in terms of the continued operation of the source VTS.
Accordingly, what is needed in the art is an improved method for exporting data tapes from a source VTS to a target VTS that mitigates the above-discussed limitations in the prior art. More particularly, what is needed in the art is an improved method for exporting data tapes that allows a continued host usage of the source tapes during a period the source tapes are being data copied from a remote cluster.